(3) Undone ワークの進め方を探る
#LeSS本
Undone ワークを誰がいつやるか？
Undone ワークの影響を知るための例シナリオ
チームは 20 個のプロダクトバックログアイテムを Done の定義に従って完成させたが、 Done の定義が弱かったので多くの Undone ワークが残っている。
https://scrapbox.io/files/649bd08043a3c7001c05c059.png
チームは 3 スプリントで 60 個のプロダクトバックログアイテムを弱い Done の定義に従い完成させた。Undone ワークが大量に増えているが、進捗していると「誤った」感覚を持つ。
https://scrapbox.io/files/649bd0cba96cfe001b72608f.png
この時点でプロダクトオーナーはプロダクトには十分な価値があると判断し、出荷することを決断した。しかし、プロダクトを出荷することはできない。弱い Done の定義であったため、膨大な量の Undone ワークを溜め込んでいる。 Undone ワークが遅延と透明性の欠如の原因となり、主要なリスクを隠してしまう。
https://scrapbox.io/files/649bd165a53110001c581df2.png
遅延
Undone ワークはプロダクトオーナーにとって柔軟性の欠如を招く
Undone ワークという仕掛りの山のせいで、マーケットのニーズや変化にうぐに対応することができない
Undone ワークを終えるのにどれくらいかかるか予測することは難しいという現実が、さらに事態を悪化させる
リスク
Undone ワークはリスクの認識を遅らせる
e.g. パフォーマンステストが Undone ワークとして残っていると、パフォーマンスの悪いシステムであるリスクがリリースに近くなるまで隠されたままになる
Undone ワークの取り扱い
Undone ワークに対処するベストでかつ「唯一の良い方法」は、強い Done の定義を使って Undone ワークを発生させないこと。これがまだ不可能な場合、一時的に必要な方法が 3 つある。
リリーススプリント
リリースの前に、チームは新しいフィーチャーの作業をせずに Undone ワークを行うスプリントを、 1 つまたはいくつか設ける
https://scrapbox.io/files/649bd3e6bd8872001c26a9b4.png
酷いアイデア
リリーススプリントはチームが Done の定義を拡張するまでの必要悪になることがある
リリーススプリントは、企業におけるデプロイの煩雑な手続きに対処する際に最もよく利用される
リリーススプリントでバグの修正を行ってはならない
リリーススプリントでテストやバグの修正を行う能力がチームにあるのであれば、通常のスプリントでもできるはず
リリーススプリントでやることを増やすのではなく、 Done の定義を拡張すべき
Undone 部門が完成させる
チームがリリースに必要な全てのアイテムを「完成」させた後、 Undone ワークを実施する専門部隊が Undone ワークを行う
https://scrapbox.io/files/649bd433febb86001beb04b5.png
ほとんどの Undone 部門は古い時代からの遺物で、チームが Done の定義を拡張するまで一時的な応急処置をする
Undone 部門の最も一般的な利用方法
自動化されていないテストを行う
チームが扱える範囲が限定されていて実行できないテストを行う
Undone 部門は従来型のプロジェクトマネジメント手法やカンバンで管理されていることがあるが、 Undone 部門のスクラムである限り、それに意味はない
すべての LeSS 導入の目標は、チームがスプリントごと、またはもっと頻繁に出荷すること
そのために余計な受け渡し、遅延、中断、リスク、学習の現象を引き起こす原因となる全ての Undone 部門を取り除くべき
Undone 部門へのパイプライン
各スプリントの終わりに、チームは Undone ワークを Undone 部門に渡し、 Undone ワークが蓄積しないようにする
https://scrapbox.io/files/649bd59667bb43001baa6542.jpg
ひどい方法
一般的に、扱える範囲の限られているチームにとっては短期間の応急処置
Done の定義を拡張し、プロダクト全体に渡る真のフィーチャーチームになって、パイプラインを取り除くべき
パイプライン化が利用されるシーン
チームのスコープがまだコンポーネントであり、テストをチーム内で終わらせることが難しい場合
テストが特別な装置を必要とし、チーム間で共有するのが難しい場合
チームが専門部門であるための言い訳ではないため、どのように複数のチームで装置を共有するかを考える必要はない
パイプライン化はうまく機能しない
Undone 部門は Undone ワークを実施する際にチームと作業する必要がある
それにより、次のスプリントでチームは割り込まれ、 Undone 部門とチームの間で継続的に衝突する原因となる
パイプライン化は言い訳。プロダクトグループが改善されるとパイプラインはなくなる
専門的な機能グループを解散しないことの言い訳
チームの扱う範囲を広げないことに対しての言い訳